AI가 "우리 회사" 업무를 이해하지 못하는 이유 (feat. 온톨로지)
온톨로지(Ontology)란 회사의 핵심 개념, 개념 간의 관계, 그리고 그 회사만의 업무 규칙을 명시적으로 정의한 지식 설계도입니다. AI가 데이터를 '조회'하는 수준을 넘어 '추론'하게 만드는 기반입니다.
데이터를 모았는데 왜 AI가 여전히 못 알아듣는가
많은 기업이 이 순서를 밟습니다.
데이터가 CRM·ERP·도면 파일에 흩어져 있다 → 데이터 사일로
그래서 데이터 레이크나 웨어하우스로 한 곳에 모은다
그런데 AI 성능이 기대만큼 안 나온다
2번과 3번 사이에 빠진 것이 있습니다. 데이터를 물리적으로 한 곳에 모아도, 데이터끼리는 여전히 서로를 이해하지 못합니다.
구체적인 예시입니다.
시스템 | 저장된 것 | 시스템이 모르는 것 |
|---|---|---|
CRM |
| 이 회사가 ERP의 거래처코드 |
ERP |
| 이 거래처가 어떤 제품을 사는지 |
생산 시스템 |
| 이 제품이 어느 고객을 위한 것인지 |
같은 창고에 넣어도 이 셋은 여전히 남남입니다. AI가 필요로 하는 것은 데이터의 위치가 아니라 데이터 사이의 의미 관계입니다.
이 의미의 연결고리를 놓아주는 계층을 시맨틱 레이어(Semantic Layer) 라고 부르고, 그 시맨틱 레이어를 만드는 설계도가 온톨로지입니다.
온톨로지의 네 가지 구성 요소
온톨로지 설계도는 네 가지로 구성됩니다. 용어는 낯설지만 개념은 단순합니다.
요소 | 의미 | 예시 |
|---|---|---|
클래스(Class) | 비즈니스의 주인공, 핵심 개념 | 고객, 제품, 주문, 공정 |
관계(Relation) | 개념 사이의 연결 고리 | "고객이 제품을 주문한다" |
인스턴스(Instance) | 개념에 해당하는 실제 데이터 | 고객 클래스의 |
액시엄(Axiom) | 예외 없는 절대 규칙 | "모든 주문은 반드시 고객과 연결되어야 한다" |
핵심은 네 번째, 액시엄입니다. 앞의 셋은 데이터베이스 설계와 비슷해 보이지만, 액시엄은 다릅니다. 회사의 업무 상식을 기계가 읽을 수 있는 형태로 명문화한 것입니다.
"우리 회사에서는 결재 없는 출고가 없다", "협력사 등급이 B 이하면 단독 발주가 불가하다" — 사람은 당연히 아는 규칙이지만, AI는 누가 알려주지 않으면 모릅니다. 2편에서 다룬 "AI는 상식적 판단을 못한다"는 한계가 여기서 메워집니다.
온톨로지 vs RAG vs 데이터 웨어하우스
셋을 혼동하는 경우가 많아 정리합니다. 대체 관계가 아니라 층위가 다릅니다.
하는 일 | 답할 수 있는 질문 | 구축 비용 | |
|---|---|---|---|
데이터 웨어하우스 | 데이터를 한 곳에 모음 | "3월 매출 합계는?" | 중 |
RAG | 문서에서 유사한 내용을 찾아 근거로 제공 | "반품 규정이 어떻게 되나?" | 하 |
온톨로지 / 지식그래프 | 개념 간 관계를 정의해 추론 가능하게 함 | "완제품 원가가 오른 근본 원인은?" | 상 |
RAG는 유사한 문서를 찾아옵니다. 온톨로지는 관계를 따라 이동합니다. 이 차이가 결정적인 순간이 있습니다.
원가 상승 원인 추적 "이번 분기 완제품 원가가 왜 올랐나?"
RAG: 원가 관련 문서 몇 건을 찾아 제시. 원인은 사람이 판단.
온톨로지:
완제품 → 부품 → 원자재 → 공급업체관계를 거슬러 올라가 특정 공급업체의 단가 인상까지 도달.
두 번째가 가능한 이유는 그 관계가 미리 정의되어 있기 때문입니다. AI가 똑똑해서가 아닙니다.
그래서, 우리 회사에 온톨로지가 필요한가
대부분의 콘텐츠가 온톨로지를 "필수 기술"로 소개합니다. 정확하지 않습니다. 온톨로지는 도메인 전문가와 설계 인력의 수작업이 필요하고, 업무 규칙이 바뀔 때마다 갱신해야 합니다. 유지보수 부담으로 실패한 프로젝트가 역사적으로 대단히 많습니다.
아래 세 가지를 모두 만족할 때만 검토하십시오.
① 답해야 하는 질문이 '조회'가 아니라 '왜'인가
"3월 매출은?"은 조회입니다. BI로 충분합니다.
"왜 이 제품군만 마진이 떨어졌나?"는 추론입니다. 여기부터 온톨로지 영역입니다.
② 여러 시스템을 가로질러야 답이 나오는가
한 시스템 안에서 끝나는 질문이라면 그 시스템의 리포트 기능이 더 빠르고 쌉니다. CRM·ERP·생산·품질을 넘나들어야 답이 나오는 질문이 반복될 때 가치가 생깁니다.
③ 그 질문이 반복되고, 사람이 매번 수작업으로 답하고 있는가
1년에 한 번 하는 분석이라면 사람이 하는 게 낫습니다. 매주 누군가 엑셀을 열어 시스템 세 개를 대조하고 있다면 신호입니다.
셋 중 하나라도 아니라면, 아직 아닙니다. 1편의 프레임으로 말하면, 온톨로지는 확률적 영역 중에서도 인과 추론이 필요한 좁은 구간을 위한 기술입니다. 그 위치를 벗어나면 과잉 투자입니다.
실패하는 방식과 시작하는 방식
검토하기로 했다면, 가장 흔한 실패 패턴부터 피해야 합니다.
❌ 실패하는 방식: 전사 온톨로지 설계
"우리 회사 전체의 개념 체계를 정의하자"로 시작하면 대부분 끝나지 않습니다. 부서마다 용어 정의가 다르고, 그 합의 과정에서 프로젝트가 멈춥니다. 완성되더라도 그때쯤 업무가 바뀌어 있습니다.
✅ 시작하는 방식: 질문 하나에서 역으로 설계
반복되는 질문 하나를 고른다 — "이 고객 이탈 위험이 높은 이유는?"
그 질문에 답하려면 어떤 개념이 필요한지 적는다 — 고객, 계약, 문의이력, 결제이력
그 개념들 사이 관계만 정의한다 — 나머지는 건드리지 않는다
작동하는지 확인하고, 다음 질문으로 확장한다
온톨로지는 회사를 다 그리는 지도가 아니라, 자주 가는 길을 먼저 포장하는 작업입니다.
지금까지 블로그 글 요약
편 | 다룬 것 | 남은 질문 |
|---|---|---|
1편 | 결정론적·확률적 업무 구분 | 확률적 업무를 뭘로 처리하나 |
2편 | 챗봇과 AI 에이전트 | 에이전트가 볼 데이터는 어떻게 준비하나 |
3편 | 섀도 AI와 데이터 정의 불일치 | 부서마다 다른 정의를 어떻게 통일하나 |
4편 | 온톨로지 = 의미를 정의하는 계층 |
2편에서 "에이전트를 움직이는 실질 동력은 모델이 아니라 접근 가능한 사내 데이터"라고 정리했습니다. 그 데이터가 서로 연결된 상태일 때 에이전트의 능력이 한 단계 올라갑니다. 온톨로지는 그 연결을 정의하는 일입니다.
자주 묻는 질문 (FAQ)
Q. 온톨로지란 무엇인가요?
A. 회사의 핵심 개념, 개념 간의 관계, 그리고 그 회사만의 업무 규칙을 명시적으로 정의한 지식 설계도입니다. AI가 데이터를 단순 조회하는 수준을 넘어 인과 관계를 추론할 수 있게 만듭니다.
Q. 데이터를 한 곳에 모으면 되는 것 아닌가요?
A. 물리적으로 모아도 데이터끼리는 서로를 이해하지 못합니다. CRM의 고객사와 ERP의 거래처코드가 같은 대상인지 시스템은 알지 못합니다. 의미의 연결고리를 정의하는 별도의 계층이 필요합니다.
Q. 온톨로지와 RAG는 무엇이 다른가요?
A. RAG는 질문과 유사한 문서를 찾아 근거로 제시합니다. 온톨로지는 미리 정의된 개념 간 관계를 따라 이동하며 추론합니다. "규정이 무엇인가"는 RAG로 충분하고, "원가 상승의 근본 원인은 무엇인가"는 온톨로지 영역입니다.
Q. 온톨로지의 구성 요소는 무엇인가요?
A. 클래스(핵심 개념), 관계(개념 간 연결), 인스턴스(실제 데이터), 액시엄(예외 없는 업무 규칙) 네 가지입니다. 특히 액시엄은 회사의 업무 상식을 기계가 읽을 수 있게 명문화한 것으로, AI가 상식적 판단을 하지 못하는 한계를 보완합니다.
Q. 우리 회사에도 온톨로지가 필요한가요?
A. 세 가지를 모두 만족할 때만 검토하십시오. 답해야 할 질문이 조회가 아닌 '왜'인가, 여러 시스템을 가로질러야 답이 나오는가, 그 질문이 반복되며 사람이 수작업으로 답하고 있는가. 하나라도 아니라면 아직 이릅니다.
Q. 온톨로지 구축은 어떻게 시작하나요?
A. 전사 설계로 시작하면 대부분 실패합니다. 반복되는 질문 하나를 고르고, 그 질문에 답하는 데 필요한 개념과 관계만 정의한 뒤, 작동을 확인하고 확장하는 방식이 현실적입니다.
온톨로지, 시맨틱레이어, 지식그래프, 엔터프라이즈AI, 데이터사일로, 넥톤, 유링파워